Proxy authentication network

ABSTRACT

A Proxy Authentication Network includes a server that stores credentials for subscribers, along with combinations of devices and locations from which individual subscribers want to be authenticated. Data is stored in storage: the storage can be selected by the subscriber. The data stored in the storage, which can be personally identifiable information, can be stored in an encrypted form. The key used to encrypt such data can be divided between the storage and server. In addition, third parties can store portions of the encrypting key. Subscribers can be authenticated using their credentials from recognized device/location combinations; out-of-band authentication supports authenticating subscribers from other locations. Once authenticated, a party can request that the encrypted data be released. The portions of the key are then assembled at the storage. The storage then decrypts the data, generates a new key, and re-encrypts the data for transmission to the requester.

RELATED APPLICATION DATA

This application is a continuation of U.S. patent application Ser. No.13/197,640, now pending, which is a continuation of U.S. patentapplication Ser. No. 11/423,565, filed Jun. 12, 2006, now U.S. Pat. No.8,028,329, issued Sep. 27, 2011, which claims the benefit of co-pendingU.S. Provisional Patent Application Ser. No. 60/690,548, filed Jun. 13,2005, all of which are incorporated herein by reference.

FIELD OF THE INVENTION

This invention pertains to identity verification, and more particularlyto the controlled release of identity information.

BACKGROUND OF THE INVENTION

In communications networks today, the devices that are used by personsor through which users are authenticated to a network are themselves insome way authenticated to a network. For example, in a typical MicrosoftActive Directory-based network (or other network that employs adirectory) a computer attached to the network receives a software-basedtoken stored on the device, and is joined (i.e., authenticated) to thenetwork. Then, when a user needs access to either the computer orresources on the network, he authenticates with a username or passwordthat is compared to what is stored in the directory. In many businessscenarios this method has proved to provide adequate security to thenetwork.

But in more secure environments, this approach to authentication has notproven secure enough. Companies such as RSA Security, Verisign, Oblix,SafeNet, and others have provided expensive two-factor authenticationusing token or token-less based add-ons that further expand on thisprinciple. Most of these solutions use public key cryptography toencrypt the transmission or token data, in order to secure the elementsof the identity. But these systems have proven expensive to deploy,difficult and costly to maintain, lack scalability for every user on theInternet, and are too complicated for the typical end user.

Another drawback to these systems is the processing overhead. In hisbook, Applied Cryptography, Second Edition, John Wiley & Sons, New York,1996, Bruce Schneier states: “Public-key algorithms are slow. Symmetricalgorithms are generally at least 1000 times faster than public-keyalgorithms”. This fact introduces limitations to widespread use of smallor low processing powered devices such as cell phones, personal digitalassistants (PDAs) or 802.1x wireless devices.

A current standard for encryption of data on the Internet is through theuse of X.509 Certificates. Certificates employ public key cryptographyand typically expire, making them a recurring maintenance cost. Themethodology behind verification of certificate-based authentication isthe use of a Certificate Authority (CA). The idea is that a user orapplication can present a certificate to a Certifying Authority tovalidate the authenticity and validity of the certificate. Presently,many companies compete in this space and there is no available scalableand affordable method to distribute certificates to every user on theInternet. Due to the need for security, the use of Certificates hascaused identities to proliferate. Many companies may have more than onecertificate from more than one Certificate Authority, making thismethodology cumbersome and inadequate. Of even greater concern is thefact that digital certificates can be forged and copied.

On the a global communications network of connected networks such as theInternet, different mechanisms exist for an Internet Service Provider(ISP) to allow access to their privately owned and controlled networkthat is connected to the Internet backbone. These mechanisms typicallyemploy both a username and password using the Remote Authentication DialIn User Service (RADIUS) protocol for wireless networks, a username andpassword for Point-to-Point Protocol over Ethernet (PPPoE) protocol forDigital Subscriber Line (DSL), or a network interface physically storedidentifier (such as a Media Access Control (MAC) address) as typicallyused in cable networks. Many other combinations of authentication andaccess to an Internet connected network also exist.

But none of these methods accurately identify the user of the deviceconnected to the network. Frequently, many users utilize a singleconnection to purchase network access to other Internet connectednetworks. In order for the Internet to function, each device connectedto it must have an assigned number. The U.S.-based Defense AdvancedResearch Projects Agency (DARPA) project that created the Internet hascreated standards of communication and control bodies by which numbersare assigned for American Registry for Internet Numbers (ARIN), InternetAssigned Numbers Authority (IANA), and others. The original design ofthe Internet was for research facilities through out the world to shareinformation easily. But the commercial value of connecting allcommunications networks soon became a more dominant use. Again, asabove, the device or network does not necessarily authenticate the user.

In 1994, the Internet Engineering Task Force (IETF) released its firstdraft for IPv6, the replacement for the current Internet standardprotocol. Within the draft of the proposal, the IETF formed a securitymethodology for secure communications. Identified in the document was adeficiency for the exchange of public keys. At the time, it was pointedout that “an Internet-wide public-key infrastructure is required”. Theencryption methodology for the secure component of IPv6 recommended inthis draft is public key cryptography. Public key cryptography typicallyuses a method for employing the encryption known as a digitalcertificate (X.509 standard). But there is another method of encryptionthat could be used, known as a shared secret. In his paper attached asAppendix A, Timo Aalto states, “[i]n manual key management, the system'sown keys, and also the keys of the communicating systems are configuredmanually to the system. This may work in a small and static environment,but does not scale”. Thus, manually configured shared secrets areuseless as a standard, as every website would have to share a secretwith its users. So today digital certificates issued by CertificateAuthorities are the current standard of distribution. However, TimoAalto also states, “[w]idespread use of IP security will require anInternet standard scalable key management protocol. A number ofcandidates of the key management protocols have been proposed: ISAKMP[“Internet Security Association and Key Management Protocol”], SKIP[“Simple Key-management For Internet Protocols”], Oakley, Photuris, andSKEME; so far none of them has been adopted as a standard. A moredescriptive information about IPv6 key management protocols can befound” attached as Appendix B. The lack of a standard has preventedwidespread use and adoption of IPv6.

In the current world of identity communication, X.509 digitalcertificates are being used to provide credentials for identity. Thesecertificates can be purchased through a Certificate Authority thatassumes the responsibility of managing the certificate's expiration.These systems involve “Web of Trust” based trust models. In order toobtain a trusted system, the scheme involves a public accounting firm tobe chosen to audit a Certificate Authority that an entity chooses totrust. Certificate Authorities issue certificates to entities through avariety of means, the most prevalent being an e-commerce applicationthat does not verify the entity except through the payment instrument.Since payment instruments can be forged or stolen, without an in personinterview there is no way to positively identify the applicant. Thecertificate model is flawed in several ways:

The process to obtain the certificate is subject to computer fraud.

Certificates can be forged, copied, and stolen.

Certificates require frequent “root server updates” to validate thecertificate.

Self Signed Certificates can be issued and generated by anyone usingOpen SSL, an open source version, and do not require a CertificateAuthority to function.

In the “Identity Commons” trust model, derived from the IntermindCorporation U.S. Pat. No. 6,044,205, the user is only registering aglobally unique name with the system. As in the CA trust model,typically the only identity verification is through the paymentinstrument. While “Identity Commons” is useful for single sign-on totrusted systems, anyone armed with the name and password can steal theidentity.

An additional problem posed by most systems in use today is there is nopositive way to identify the user of a device. For example, in the cellphone network, typically devices are authenticated for use by anidentifier stored in the device. However, in this example, there is nopositive way to identify the user of the device. The device typicallyhas a way to lock the keypad with a code only known to the user toprevent unauthorized use; but to date, there is no positive way toidentify the user. Inventions exist to tie the device to a user, such astoken-less biometric sampling, the use of a personal identification codeor number (PIC or PIN), a token such as a credit card, and other tokenor token-less methods and combinations thereof. But in the case of acell phone, these inventions have proven to be cumbersome, expensive,defeatable, or for other reasons not implemented.

In the telephone network a number is assigned to wires run to a home orbusiness. As above, there is no positive way to guarantee the user'sidentity.

In the Automated Teller Machine (ATM) network, an ATM is authenticatedand monitored through software. But since most of these networks rely onthe use of a token, such as a credit card, that can be passed to anotheruser or stolen, once again there does not exist a method to verify theauthenticity of the user of the token. Biometric devices are seen as thesolution to this problem. But biometric devices have seen slow adoptionfor a variety of reasons that are primarily behavioral in nature (fearof germs, etc.), not to mention that the reasonably priced models can bereadily defeated.

Identity theft is another problem area resulting from software intrusionthat captures an end user's keyboard input and can capture screen shotsof the user's personal computers allowing them to pose as the identity.In fact, many of these intruder programs are sophisticated enough toturn on an attached camera or microphone and actually listen to or viewwhat is in the room with the computer! The number one intrusion iscapturing a user's keystrokes as they input a username and password, toaccess financial or other data.

Another form of identity theft comes from what are referred to as“phishing emails”. These emails are carefully crafted and contain a linkto a false web site masquerading as the real site. When the userauthenticates to (what he or she thinks is) the real site, the falsesite is able to capture the user's credentials. Today, there is nosimple, reliable way to communicate to the unsophisticated user thatthey have accessed an application that does not belong to the entitythey believe it to be.

Accordingly, a need remains for a way to authenticate users withoutrelying on certificates, usernames and passwords, and other techniquesthat can be intercepted, forged, or captured by deception that addressesthese and other problems associated with the prior art.

SUMMARY OF THE INVENTION

One embodiment of the invention includes a system and method forperforming a transaction. Subscribers register with the system and areprovided credentials. The subscribers can be authenticated using theircredentials. A receipt can be provided to the subscribers. The receiptidentifies the two subscribers without providing any personallyidentifying information about the subscribers.

Another embodiment of the invention provides for the release of dataencrypted by a key. The key is divided among a number of participants.When the data is to be released, the key is assembled from the variousportions. The data can then be decrypted. The data can be re-encryptedusing another key for transmission to a requester of the data, toprotect the data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a Proxy Authentication Network, according to an embodimentof the invention.

FIG. 2 shows the steps used in authenticating an entity using the ProxyAuthentication Network of FIG. 1.

FIG. 3 shows the steps used in the identity announcement protocol usingthe Proxy Authentication Network of FIG. 1.

FIG. 4 shows a trust model implemented using the Proxy AuthenticationNetwork of FIG. 1.

FIG. 5 shows the master ID table used in the Proxy AuthenticationNetwork of FIG. 1.

FIG. 6 shows an input schema used in the Proxy Authentication Network ofFIG. 1.

FIG. 7 shows the location table used in the Proxy Authentication Networkof FIG. 1.

FIG. 8 shows a schema for devices used in the Proxy AuthenticationNetwork of FIG. 1.

FIG. 9 shows an identity table used in the Proxy Authentication Networkof FIG. 1.

FIG. 10 shows the topology of identifier data in the ProxyAuthentication Network of FIG. 1.

FIG. 11 shows the topology of encryption keys in the ProxyAuthentication Network of FIG. 1.

FIG. 12 shows some of the tables used in the Proxy AuthenticationNetwork of FIG. 1.

FIG. 13 shows how a call can be transferred to an operator in the ProxyAuthentication Network of FIG. 1.

FIG. 14 shows how a shared cryptographic secret can be distributed inone embodiment of the Proxy Authentication Network of FIG. 1.

FIG. 15 shows how a shared cryptographic secret can be distributed inanother embodiment of the Proxy Authentication Network of FIG. 1.

FIG. 16 shows how identities can be created in the Proxy AuthenticationNetwork of FIG. 1 using a Sovereign System Identifier.

FIG. 17 shows how the Proxy Authentication Network of FIG. 1 can be usedby law enforcement to access authentication log data.

FIG. 18 shows a network operations module can be used in the ProxyAuthentication Network of FIG. 1.

FIGS. 19-20 show the operation of the messaging interface of FIG. 18.

FIG. 21 shows key generation in the Proxy Authentication Network of FIG.1.

FIG. 22 shows the storage access server in the Proxy AuthenticationNetwork of FIG. 1.

FIG. 23 shows the use of the location identifier in the ProxyAuthentication Network of FIG. 1.

FIG. 24 shows a string representing a fully authenticated identity inthe Proxy Authentication Network of FIG. 1.

FIG. 25 shows a mutual authentication receipt generated in the ProxyAuthentication Network of FIG. 1.

FIGS. 26A-26B show a method of use of the Proxy Authentication Networkof FIG. 1.

FIG. 27 shows the start-up process for a client using the ProxyAuthentication Network of FIG. 1.

FIG. 28 shows the start-up process for a service control module in theProxy Authentication Network of FIG. 1.

FIG. 29 shows the location of the encryption driver in a personalcomputing using the Proxy Authentication Network of FIG. 1.

FIG. 30 shows an identity credit input process using the ProxyAuthentication Network of FIG. 1.

FIG. 31 shows the start-up process for a client using the ProxyAuthentication Network of FIG. 1.

FIG. 32 shows an initial credential process using the ProxyAuthentication Network of FIG. 1.

FIG. 33 shows a primary credential process using the ProxyAuthentication Network of FIG. 1.

FIG. 34 shows a protocol model usable with the Proxy AuthenticationNetwork of FIG. 1.

FIG. 35 shows various computers connected to the Proxy AuthenticationNetwork of FIG. 1.

FIG. 36 shows the server of FIG. 35 storing credentials used toauthenticate an entity.

FIG. 37 shows the states of the credentials of FIG. 36 being changed.

FIG. 38 shows an encryption key being assembled from various portions inthe Proxy Authentication Network of FIG. 1.

FIG. 39 shows components of the storage of FIG. 35 used in accessingdata in the storage.

FIGS. 40A-40C show a flowchart of the procedure to authenticate anentity in the Proxy Authentication Network of FIG. 1.

FIG. 41 shows a flowchart of the procedure to add data to a storage inthe Proxy Authentication Network of FIG. 1.

FIGS. 42A-42B show a flowchart of the procedure to access data in theProxy Authentication Network of FIG. 1.

FIG. 43 shows a flowchart of the procedure to communicate using a proxyin the Proxy Authentication Network of FIG. 1.

DETAILED DESCRIPTION

Microsoft Corporation, in an article appearing on the Internet as of May11, 2005, titled “The Laws of Identity” by Kim Cameron, attempts todefine digital identity. Within this published work are the followingreferences: “Problem Statement—The Internet was built without a way toknow who and what you are connecting to”. Additionally, Microsoftpublished “[s]ince this essential capability is missing, everyoneoffering an Internet service has had to come up with a workaround. It isfair to say that today's Internet, absent a native identity layer, isbased on a patchwork of identity one-offs”.

There is not a single authoritative system and methods for establishinga “sovereign digital identity”. The problem is the abstraction ofdigital identity itself as it is only a representation of a real person.A myriad of “identity one-offs” exist as valid credentials to representoneself to a network system. Usernames and passwords, digitalcertificates, smartcards, tokens, biometric devices and other methodsexist in the form of credentials and each credential is unique to thatsystem.

Kim Cameron has made available a paper titled “The Laws of DigitalIdentity” which further confuses the actual reality of “digitalidentity”. It is an attempt to “systemize” identity. Digital Identity,as defined here, is the presentation of valid credentials to a systemthat recognizes you and can verify you outside the medium ofconnectivity.

Kim Cameron also states “limn summary, as grave as the dangers of thecurrent situation may be, the emergence of a single simplistic digitalidentity solution as a universal panacea is not realistic.”

A global system of identity credentials embedded in the entity that arein constant communication with a system connected to a GlobalPositioning System that tracks the actual entity in reality is notdesirable from the standpoint of privacy, and is not possible when theentity is a commercial entity like a corporation or partnership.Therefore, a system needs to be in place to allow for a sovereignidentity representation of the entity with sufficient methods to verifythe actual entity in reality with the entity having the ability andcontrol to terminate such a representation.

The Proxy Authentication Network is a system and method to establish an“identity layer” where an entity claims and controls the credentials toaccess the layer as sovereign: that is, no other set of credentials ismore representative of themselves in the medium of access. The systemalso prevents an entity from presenting to the system more than one setof credentials at one time. The system optionally stores a mastercredential for use by the entity or those authorized for the purpose ofautomatically scheduled payments or other methods of conducting digitalcommunication or digitally signing documents. This master credential canbe used by other authorized entities within the system, under control ofthe owning entity, when the entity is connected or not connected to thesystem. The Proxy Authentication Network provides this control.

A set of credentials, in the context of the Proxy AuthenticationNetwork, is a user configurable set of tokens or token-less input, thedevice accessing the medium and the physical point of connection to themedium. To verify these credentials, as they can and will change, asystem is in place to verify the identity outside the medium ofconnection. The medium of access can be any network connected to theProxy Authentication Network. For instance, if the user were on a cellphone network connected to the Proxy Authentication Network and wishedto authenticate, they could use a computer connected to the Internet toverify the cell phone medium. Out-of-band authentication to a proxynetwork acting on behalf of the entity who has declared this to be theirsovereign representation of themselves within the access medium andsystem to positively authenticate the entity in the real world is new.FIG. 1 shows an embodiment of the invention. FIG. 34 shows the protocolmodel, depicting an embodiment communication structure. Of note is theHybrid IPSec acting as a bather to the actual Proxy AuthenticationNetwork.

FIG. 2 shows the steps of a typical authentication process within anembodiment of the invention. In step 201, under control of the entity,the client software is initialized and the various identifiers used todifferentiate the device from other devices attached to the network areauthenticated by the node access server process. In step 202, undercontrol of the entity, the client software requests the credentialsidentified in the entity credential profile table stored by the system.In step 203, the access device and entity credentials are stored on akey server and the server writes the derived identity credentials intothe volatile memory of the server creating a RAM based state table. Thisidentifier is used in mutual authentication by the system to quicklyauthenticate a user who wishes to access their master or slave datastorage locations and generate an audit trail. The identifier isparseable and is logged. In step 204 a client, as illustrated in FIG. 3,has invoked the mutual authentication receipt method. This process takesthe new authentication identifier from RAM on the appropriate keygeneration server of each authenticating entity and combines themtogether to form an authorized receipt. This receipt can then bepresented to a data access method and the requesting entities can acceptor reject the transfer of information. The transfer of information canbe in the form of simple fields displayed to the entity from a basicdata request method or it can invoke a transaction interface that islinked to the proxy authentication network transaction method interface.

Returning to FIG. 2, in step 205, the client has requested dataaccording to one of the afore mentioned processes, after querying theaccess policy filter for a method, in this case the “unlock location”method is called and the participating servers send the encryptedpartial keys to the appropriate master or slave location where they areassembled for verification and the data access is granted. In step 206,the access policy filter is requested again and calls the appropriatemethod for the release of data. In this step, the actual data can bedisplayed to the user for verification. In step 207, the negotiatedamount of data is sent to the requesting entities.

The guiding principles of embodiments of the invention are:

-   -   1. Store an identity in only one location.    -   2. Create a central authority for authenticating the entity    -   3. Create a storage provider for the entities identity and        personal information    -   4. Use metadata and pseudo data so that the central authority        does not know the true identity of the entities contained in the        storage provider facility.    -   5. Optionally, introduce a third party to prevent collusion        between the central authority and the storage provider. An        appropriate metaphor is the Judicial, Legislative, and Executive        branches of the United States of America.    -   6. Introduce a method of logging and access to prevent abuses by        any party participating in the process including collusion        between all three parties.    -   7. Introduce a method whereby an enforcement body can receive        log data of mutual authentications for enforcement or other use.        An example is depicted in FIG. 17.    -   8. All devices, users, sites, and hosts (objects) are        authenticated at all times into an “authenticated identity        virtual network matrix”.    -   9. In order to safeguard entry into the proxy network any        authentication request is denied or ignored unless it comes        directly from a previously authorized device. A client server        based authentication sequence is initiated between a plurality        of servers depending on the type of authentication request.    -   10. In some embodiments, network countermeasures are invoked to        protect the proxy network from Denial of Service Attacks or        unauthorized intrusion.    -   11. Utilize hardened, highly secure servers with intrusion        detection systems, self-destruct on intrusion, and triple        redundant safeguards to defend and insure a projected 99.99%        uptime. Each server is installed in a “cluster” consisting of        two identical servers that are connected by a “heartbeat”        program that in the event of any failure in the primary server        automatically the other server begins processing, providing a        projected 100% uptime for the network itself. Additionally,        another cluster of servers that is duplicated through an imaging        protocol exists in another location, should the first location        become unavailable.    -   12. Prevent the client from accessing the network directly using        a “reverse firewall”.    -   13. Allow sub storage of additional information such as medical        records, additional financial information, or documents        generated by the user.    -   14. Use discrete functionality as in an embedded system that is        usually low in system resources in a system with plentiful        processing resources.    -   15. Use a database structure for client requests that responds        directly to a network.

Embodiments of the Invention consist of a proxy authentication networkof servers that have databases containing information unique to the useror site and the hosted devices but possesses no personally identifiableinformation other than an age group identifier for users to assist incomplying with an “Internet use law” that is required (adult, under 13or 13 to adult) or in another embodiment where a site entity may possessa website content rating. Additional information stored on servers caninclude a derived network identifier and a location table that is usedby the system to assist in locating the user/device pairing. This is aunique identifier and is known only to the system. The network accesscode is an internal security measure to assist in insuring against falseauthentication attempts. The first server process controls communicationto users and devices and has an ad hoc state table that joins theuser/site to the device and “virtualizes” the pair into a time stampedmatrix. From this point on an authentication request is fulfilled when aclient request matches the kernel state table. In the event anauthentication request is received and in the event a site or otherobject requests personally identifiable data concerning the user, arequest for data is initiated and directed to the client that transmitsthe request after receiving a special key called the mutualauthentication receipt sequence from a server. A second (or conceivablythe same) server exists in close proximity to the personal informationdata store, usually a network known as a “DMZ network” that existsbetween the internal private storage network and the Internet. Theserver is connected to the Internet or a firewall device at the Internetand contains data access security and requests methods. All servers areconnected through a virtual private network and under control of anetwork operations center program to manage the network.

The system is a voluntary identification computer system frameworkwherein all objects are identified and authenticated whose use isintended for determining an individual's or business's or device'sidentity and granting access to personal or business information fromexamination of one or more token or token less identifiers gathered atthe time of use of the computer system and comparison with previouslyrecorded or assigned data gathered during a registration step, whereinthe individual, device, or entity is authenticated to the system and thesystem grants access to information as previously determined during theregistration step or modification of those terms as amended from time totime by the user comprising an in person input process, a sovereignstorage location, control methods for access to the storage location, aremote validation authority for access to the storage location, a methodof reporting false attempts to authenticate or generate a transaction orcreation of an identity that is forwarded to appropriate lawenforcement, a plurality of servers that store identifiers that are apseudonym for real data and coded identifiers to identify thecredentials of both the user and the device used to access the system.

Trust Model

In the Proxy Authentication Network trust model, illustrated in FIG. 4,the entity implicitly trusts the identity storage location and through averifiable identity process at the storage location, the storageprovider subsequently trusts the identity. The storage provider eithertrusts or partially trusts the proxy network provider and the proxynetwork provider trusts or partially trusts the identity storageprovider. In the case of partial trust they introduce a third party tomonitor and audit authentications and access to the identity storagelocation. The proxy network provider does not trust the entity and thethird party auditor does not trust the proxy network. The entity onlytrusts the proxy network with authenticating their existence and ifimplemented this existence can be verified outside of the primary mediumof communication—out of band confirmation of authentication.

In whatever location an entity's identity related data is physicallystored, the entity must first establish a single instance of trust tothe proxy network before access to identity data is located or to obtainthe “keys” to another trusted storage location. Because the entity doesnot trust the proxy network with identity data, the proxy network doesnot possess identity data beyond unique identifiers that comprise theauthentication data, and in one embodiment an age group identifier. Theproxy network provider only shares in “key management” andauthentication of the entity. In this way, relative anonymity can bemaintained for the entity. Access to the identity storage locationrequires a set of “keys” that are shared by the proxy network, the thirdparty (if implemented) and the storage provider. All of the “keys” mustcome together in one location in order to “unlock” the identity data.This is required before access to the data is granted to and by theproxy network provider on behalf of the entity.

In this identity scheme, the identity is tied to user configurablecredentials that are instantiated at one place in time and optionally,the “identity” or master credential can be stored in a remote physicalstorage location. To provide relative anonymity to the entity, thesystem uses a proxy network that possesses little or no personalinformation about the user. In the case of a business entity, the entityis tied to authorized credentials of individuals and managed by a policyfilter.

Data Operations

Master Identity

The proxy authentication network system possesses a master database(though this may be distributed in nature) with a single referenceidentifier, for accessing data that is the “Master Identity” storagelocation. This identifier could be, for example, an entity's socialsecurity number that is affected by a one way transform, which suppliesthe necessary unique identifier required by the system. However,additional storage of entity related data can be linked to the masterlocation. The sovereign location holds the rights, and can hold anysubsequent policy right for another slave location for any access ofslave data. This provides centralized control to the user over theirdigital assets. A simple database of entity identifiers and theidentifiers authorized to access is maintained. The control interface ismost likely a web application outside the embodiment of the invention.The process to link slave data is performed at the sovereign location. Asimple table, such as shown in FIG. 5 is used.

Generating Globally Unique Identifiers (GUID)

Globally unique identifiers that tie the entity to the system are used.There are two important identifiers, the Master Entity Identifier andthe System Entity Identifier. One way to create these identifiers isdepicted in FIG. 16. The Master Entity Identifier is used in the inputprocess. There is an input process at some place like a bank (InputAuthority) where a user's identity is verified in the real world (photoid etc.). At the time of the verification there is also the possibilityof collecting a biometric. A biometric is simply a mathematicalstatement of a unique identifier, so it is possible to create a uniqueidentifier through the input process without using biometrics. Thisglobally unique system identifier is in a master database that isreferenced by the input application so that anyone who tries to maintainmore than one “master” entity identifier is prevented from doing this.The input process collects personally identifiable information and aseries of questions and answers that the identity would be confident fewpeople would know the answer to and more importantly it would beunlikely anyone would know all the answers to. Mother's maiden name,last pet, favorite color, etc. are also collected. In the instance of acommercial entity, the questions could be something like tax id,mother's maiden name of contact principle, registered agent or otherquestions unique to a business and the businesses registered entity(person). This is a little more difficult because public entities have alot of public information. These questions are important because both anautomated and a non-automated call center will query the identity of theuser and pose these questions to verify the identity of the user. In alarger corporation there can also be a company hosting a plurality ofweb sites, and in the process each separate site, including mirrorsites, would receive a unique identifier. Business entity identifiersare the entity's primary identifiers and the person registered toperform authentication for the entity. In the case of a distributedwebsite the authentication mechanism can be a USB or other token that isconnected to the computer. To authenticate the website to the systemwill require a duly authorized administrator who is known by the systemto authenticate first, and then with an out of band verification insertthe token representing the business entity. In this way, a businessentity maintains control of the credentials used.

Through out the proxy network and in the fulfillment center are metadatakeys. These are unique strings that point to key fields in varioustables. For example “Master Encryption Keys” are parsed into pieces andencrypted with different keys for each row of data. The master keys arethen deleted from the tables destined for the storage access server.Each row of data has a unique master key that is only stored with theoriginal data.

FIG. 24 depicts the fully authenticated identity. The string is storedin the RAM of the key generation server and contains the Location IDwhich is the server RAM it is stored on, a timestamp that is used by theserver to remove identities after a determinate time period ofinactivity, it is also part of the audit log, and is used fortransmission in when a mutual authentication receipt is requested. Thebalance of the string represents the authenticated device used for thesystem id pairing of device to entity system master id. The string alsocontains the identifier generated from a transaction where by an out ofmedium authentication takes place.

Registration Process

In one embodiment, entities register with the system through an inperson interview process. Employees of a business entity that isregistered with the system each register separately, and utilization ofthe proxy authentication network by a business entity can be considereda slave location. The primary use of the registration process for abusiness is to allow an application server, such as a website, to beauthenticated to the proxy authentication network so that the system'sauthentication and subsequent data request methods can be called toobtain authentication and information from entities who invoke theIdentity Announcement Protocol depicted in FIG. 3 when accessing theapplication. A representation of the table is depicted in FIG. 6.

Database Schemas

The schemas involve storing encrypted entity data and encrypted partialkeys for the data. The keys to decrypt the data are broken into keyparts and encrypted then separated amongst operators of the system tomake theft more difficult. The actual data key parts themselves areencrypted with a key stored with the encrypted entity data. The masterkey is stored in the original database and not with the encrypted data.This assists in assuring the wrong entity data is not released, for whenthe key parts come together at the storage access server, the datacannot be decrypted if the wrong key or entity were selected. Thoseskilled in the art will see that the schema designs place only metadataonto the proxy network provider and optionally a third party control andkey storage server. There are tables for communications, credentials andcredential management. FIG. 7 is an example of the table used forlocating servers or storage locations. Those skilled in the art willquickly see that the tables in the proxy network provider's databasescontain no personally identifiable information regarding an entity. Inone embodiment an age group identifier may be collected for minorchildren in the interview process, to assist in protecting children whoattempt to access applications of entity sites for which they may beforbidden by law. FIG. 8 is an example of a schema for each device. FIG.9 is an example of an Identity table. It is through a relational designby those skilled in the art that the identifiers are appropriatelystored to provide the functional design of the system.

The schemas relate to one another, while creating layers of protection.FIG. 10 depicts the first layer, separating the identifiers used in thestorage provider from the proxy network provider and optional trustedthird party. In FIG. 11 the separation of the encryption keys stored bythe system is depicted. The number of key parts and participatingentities is only limited by reasonable response time for transmittingthe data. In FIG. 12, the system tables are depicted for an embodimentof the invention.

Logging Functions

Logging functions, while captured on the proxy network provider serverare, as in the network born key parts, stored amongst the membersparticipating in the management of the network and are similarlyencrypted and parted. This is to aid in the prevention of log harvestingand to prevent the possibility of an intruder capturing log data fromthe system and eventually decrypting log data to gain an advantage inthe system.

Credential Input Profile Changes

In one embodiment users have control over their input credentialsthrough a secure web based application hosted at their respectiveprimary data storage locations. When a user reconfigures their inputidentifier profile or if somehow a user input profile were modified, thedatabase calls a stored procedure that alerts the system to a profilechange. If the entity is authenticated, a message is passed to the userinterface, notifying them of the change, in addition to the webcredential management dialog confirming the changes. This is to aid inclient intrusion. If the entity is not authenticated and a change takesplace a system intrusion alert is sent, and the profile and entity istaken off line until a verified authentication take place.

Out Of Medium Authentication

Automated Call Center

An automated call center is the first out of band authenticationconfirmation mechanism. The call center out of band verification processcan be configured a number of ways. A modem bank can be configured atthe center to receive and transmit data directly to a PC throughtelephone lines if the primary medium is a broadband connection. Anentity can also dial a telephony application that allows the entity toinput the desired information. In another embodiment a cellulartelephone can be used, and this can be an application on the cellularphone communicating with the call center on the Internet through a webapplication. While the medium of access is technically the same, theauthenticating device is different, providing an exemplary embodiment ofthe invention by illustrating the authentication verifying device beingseparate from the device to be authenticated. In this embodiment, thecontrol of the authentication is from two distinct devices and the callcenter verifies each device communication through an input request,effectively providing an out of band authentication as the confirmationis controlled through two different devices providing a mutualauthentication with appropriate input strings. In practice, for securityreasons, this embodiment will also require input of the fulfillmentcenter re-authentication string.

Manual Call Center

The manual call center is available when the automated system fails. Themanual call center can be configured to transfer the request for answersto the personal questions from the interview to a third party,effectively preventing the proxy network provider from gathering anypersonal information regarding the entity. Optionally, in the interviewprocess, an alias for the entity can be gathered for the proxy networkprovider to address the entity that prevents the proxy authenticationnetwork or optional third party monitor from knowing the true name ofthe entity whose personal information is being queried. When a thirdparty verification transfer takes place the logging sequence is changedto aid in the verification of the entity, and to allow for the gatheringof information suitable for confirming the call. An embodiment isdepicted in FIG. 13. As in the regular logging sequence, upon completionthe log data is encrypted and redistributed.

Multiple Medium Access

Regardless of the medium of access, only one device/identity pairing canbe authenticated at one time. For example if a user is “online” i.e.,fully authenticated at their computer, and they attempt to authenticatewith their cellular phone to a web portal the authentication will bedenied and the system will register a message to the “online” devicethat an access by “device friendly name” has been attempted. In anotherexample if the user is authenticated on their cellular phone or workcomputer and someone attempts to use a registered device a message isdisplayed on the online device “device friendly name” has attempted toauthenticate. The security benefit outweighs the inconvenience and thisis required as the cellular phone can also be used as a separate mediumof distributing pre-shared keys.

Key Distribution and Verification Methods

In one embodiment of the invention a cryptographic key managementprotocol where the shared cryptographic secret for two hosts tocommunicate with each other across a network medium A is generated andencrypted then distributed through medium A to the first host anddelivered through medium B to the second host and the transmission isthen verified through medium C. This is depicted in FIG. 14.

In FIG. 14, Alice 1405 sends Bob 1410 encrypted session key 1415.Encrypted session key 1415 is sent through a medium A. For example,medium A could be a postal service. But a person skilled in the art willrecognize that medium A could be any other desired medium, such as asecured connection or a telephone call, as could all other mediums usedin other implementations. Further, although the various mediums aregiven labels, it is not required the mediums be different. For example,Alice 1405, Bob 1410, and Carmen 1420 could all be communicating acrossthe same medium.

The Proxy Authentication Network checks to see if encrypted session key1415 is in the table for Bob 1410. If not, then Bob 1410 sends Alice1405 a notice that the key is invalid. Bob 1410 then does not acceptcommunication from Alice 1405 without confirmation from Carmen 1420.

Assuming that encrypted session key 1415 is in the table for Bob 1410,then Bob 1410 sends Carmen 1420 notice 1425 via medium B that Alice 1405wants to set up a cryptographic tunnel. Carmen 1420 sends Bob 1410 anacknowledgement (shown in FIG. 14 as part of Notice/Acknowledgement1425) of the request, and waits for Alice 1405 to communicate withCarmen 1420 through medium C. Bob 1410 also decrypts encrypted sessionkey 1415, and uses the decrypted key to send Alice 1405 an encryptedmessage explaining how to confirm the key with Carmen 1420.

Alice 1405 then sends Carmen 1420 verification value 1430. Carmen 1420verifies verification value 1430 with Bob 1410, which confirms thatAlice 1405, Bob 1410, and Carmen 1420 are communicating.

Where a channel needs to be secure, a person skilled in the art willrecognize that the channel can be secured in different ways. Forexample, the channel can be a physically secure channel, where nounauthorized party can interfere with the channel. Or the channel can bea physically insecure channel over which a secure encryptedcommunication is occurring. A person skilled in the art will recognizeother ways in which channels can be secured.

A cryptographic key management protocol where a secret value to generatea cryptographic secret for two hosts to communicate across medium A isgenerated and encrypted and delivered to one host through medium B andto another host through medium A whereby Alice initiates communicationwith Carmen through medium C and a value is given to Carmen and Carmentransmits a matching value to Bob through medium A confining hostcommunication. This is depicted in FIG. 15.

In FIG. 15, Alice 1505 and Bob 1510 negotiate secure channel 1515.Negotiated secure channel 1515 can use any known technique to secure achannel across medium A. Bob 1510 then sends Carmen 1520 notice 1525.Bob 1510 also sends Alice 1505 an encrypted message explaining how toconfirm the communication with Carmen 1520. Carmen 1520 sends Bob 1510an acknowledgement (shown in FIG. 15 as part of Notice/Acknowledgement1525) of the request, and waits for Alice 1505 to communicate withCarmen 1520 to confirm the communication.

Alice 1505 then sends Carmen 1520 verification value 1530 across mediumB. Carmen 1520 transmits a value to Bob 1510 that confirms that Alice1505 and Bob 1510 are communicating. Carmen 1520 can also issue newshared secrets to Alice 1505 and Bob 1510, across the mediums.

Alice and Bob need to authenticate securely and absolutely, that is theyboth need to determine that the digital representation of each otherexist in a single point of time by reference to the primary accessmedium they are communicating through. Alice and Bob also need theability to turn off access to their unique digital identity (UDI). Aliceand Bob agree to allow Carmen to proxy their requests to the location oftheir unique digital identity. Alice and Bob also agree to allow Carmento pinpoint the access of one another and limit the access to a singlepoint of access and decide whether Alice and Bob do indeed exist byquerying outside the medium which they are communicating through. At thesame time new encryption keys can be generated for Alice and Bob anddistributed both “in and out of band”. It is understood that Bob andCarmen are able to communicate securely over medium A or any othermedium.

Credential Proxy Request

Alice and Bob agree to allow Carmen to be the proxy through which Aliceand Bob communicate with themselves and Diaz, where the actual UDI isstored. In order to accomplish this goal a different medium isintroduced to pass authentication messages to the system. Because Aliceand Bob wish to pass messages or data to each other and have thatmessage authenticated into reality, Alice and Bob realize they mustdeclare a sovereign digital identity (SDI) for themselves. Alice and Bobagree to store their SDI in only one location. Alice and Bob agree totrust Carmen implicitly for communication between Alice and Bob andagree to use Diaz or whomever Carmen trusts as the storage provider fortheir sovereign digital identity data. However, Alice and Bob also agreethat a fourth, fifth or sixth party, Evelyn, Frank, and Giuseppe, couldall or more confirm access by Carmen to their SDI as well as preventDiaz from disseminating their SDI. Diaz splits the information necessaryto obtain access to the SDI between the number of parties required tosatisfy the authentication requirements of Alice and Bob respectively.Alice and Bob also agree to perform an in person interview whereby theygive Diaz (or any additional entity that Carmen trusts) the actual datacomprising their sovereign digital identity. The digital identity isthen encrypted by Diaz (or any additional entity that Carmen trusts) andDiaz separates the keys required apportioned to the number of fourthparties Alice and Bob agree to. Alice and Bob simply choose to separatetheir declared sovereign digital identity and agree to give Carmen proxyrights for communicating requests for authentication and of theexistence of Alice and Bob in reality at the time of their creation ofany digital representation of themselves.

Alice, Bob, Carmen, and Diaz all trust each other. In another embodimentof the invention Alice could trust Evelyn with the interview and Alice,Bob, Carmen, Diaz, and Evelyn could trust Frank with authenticating thecommunication from Alice, Bob, Carmen, Diaz and Evelyn. It is importantto understand that the invention allows multiple Diazes and Franks.

In RFC 2627—Key Management for Multicast: Issues and Architecturessection 5.1 MANUAL KEY DISTRIBUTION, it states: “[t]hrough manual keydistribution, symmetric key is delivered without the use of public keyexchanges.” It further states that “[t]he Net Keys would be distributedto each individual group participant, often through some centralizedphysical intermediate location. At some predetermined time, all groupparticipants would switch to the new Net Key.” In this scenario, analternate key is also discussed in the event a compromise of theoriginal key is made, and that said alternate key would also bedelivered “out of band”, suggesting perhaps that the key would bedelivered in the same process as the original key.

Alice and Bob are authenticated in reality to a trusted system by an inperson interview with Carmen whereby they declare a sovereign digitalidentity and agree to have Carmen store their sovereign identity. Aliceand Bob are given a matching session key from a trusted third party Diazand pass messages through trusted third party Evelyn who is trusted byAlice, Bob, Carmen and Diaz. The actual data is stored at Carmen. Carmenand Diaz confirm the messages from Evelyn for data on behalf of Aliceand Bob.

In another embodiment of the invention Alice and Bob need toauthenticate securely and absolutely, that is they both need todetermine that the digital representation of each other exist inreality. Alice and Bob are authenticated to a trusted system by an inperson interview with Carmen whereby they create a sovereign digitalidentity. Alice and Bob are given a matching session key from a trustedthird party Diaz who Alice, Bob and Carmen trusts and pass messagesthrough Diaz. The actual data is stored at Carmen. Carmen and Diazconfirm the messages from Alice and Bob for authentication requests fromCarmen for data on behalf of Alice and Bob.

Alice and Bob need to authenticate securely and absolutely, that is theyboth need to determine that the digital representation of each otherexist in reality. Alice and Bob decide to trust Carmen with the storageof their data and Carmen encrypts the data from Alice and Bob. Alice andBob also trust Diaz with communicating with Carmen on behalf of Aliceand Bob and decide to trust Evelyn with keeping Carmen and Diaz honest.Carmen gives Diaz and Evelyn a partial key and a row identifier forAlice and Bob in Carmen's database. If Alice and Bob decide they couldalso invite Frank and Gordon or more into their circle of trust toexpand the number of keys required for greater security. In this wayadditional parties are introduced for the sharing of partial keys toallow access to their data.

In order to protect against flooding attacks from devices to node accessservers, the AH of IPv4 tunneled IPSEC or the AH of IPv6 is used,depending on what IP protocol is available for communication. Typically,other protocols employ the use of a cookie as in IBM's patentincorporated in RC2522, or in the Kerberos protocol, the TLS 1.0, andothers. This is because these protocols deal with peer-to-peercommunication and may not know the device they are communicating with.In the Proxy Authentication Network, the device used to authenticate theidentity is assigned at the initial authentication by Carmen and Diaz.Shared secrets are known (or expected) before communications begins.

Self Authentication

An example of this embodiment follows. The user is attempting toauthenticate to a public terminal: for instance, an ATM machine. Theuser has inserted the token and entered the PIN, however, the user hasspecified in their in person interview that they want ATMs that areconnected to the proxy authentication network to require an additionalProxy Authentication Network verified receipt. The account is flagged asa Proxy Authentication Network account in the main processor of the ATM.In order to finish the authentication, the ATM machine would have topossess the necessary hardware to authenticate the user with their ProxyAuthentication Network token or Tokenless choice of authentication orcombination thereof. However, if the ATM machine is an ProxyAuthentication Network authenticated device, without the additionalhardware, or a telephone link to the call center, the user could utilizea cellular phone to contact the call center and select “I am at an ProxyAuthentication Network enabled public terminal” from the automated menu,at which point the cellular phone would require authentication throughthe users cellular pass code (or biometric or token or all three) andthe ATM would display a code to be entered into the cell phoneconfirming an authentication to ones self. Another variant is if thecellular phone is not a Proxy Authentication Network enabled device theuser could still authenticate to the call center through voiceinteraction and provide the ATM designator. This method would requirethe correct answer to a minimum of one security question from theoriginal in person interview. In either of these cases twoauthentication receipts would be given, one for the cellular phone callto the call center and one for the ATM.

Other devices could also be used like a PDA that has a wirelessconnection to the Internet could logon to the web-based call center andperform a full authentication, enter the ATM machine code at which timethe ATM will display a code to be entered into the PDA and theauthentication would be granted. Two authentication receipts would begenerated under this scenario as well.

Yet other devices with which the system can be used might include aSession Initiation Protocol (SIP) phone that has a wired or wirelessconnection to the Internet. The SIP phone can be a device that hascredentials of its own managed by the system, and can be identified bythe system.

System Messages

Most system messages are predetermined and read from a table stored onthe server that the client or server is accessing. There are two groupsof messages, control messages used by the various software modules onthe server and security messages which are transmitted by the networkoperations center. A security message is created anytime there is asecurity event, which is defined as any event that halts normalprocessing. The Network Operations Module depicted in FIG. 18 undercontrol of the network operations center transmits the message to theclient and if appropriate other servers or a law enforcement agency.

Address Registration

The Proxy Authentication Network does not use DNS for establishingcommunications between servers. Network control of the destination of apacket is controlled through the use of location identifiers. This isdone as much for speed as for security, since the network databasescontain the location of all servers and are local, no DNS request isnecessary. This further enhances system security as the location ofservers is not publicly known, and requests for a name cannot beintercepted. Each server that comes online, and joins the network,performs the following procedures. The server is assigned a networklocation identifier (i.e. name) by the network operations center. Thisis an arbitrary identifier that is unique to each server. Thisidentifier can be used in the SA portion of the SPI for IPv6communications. Every server's allowed communications table in itsoperational database is then updated with the actual IPv6 or IPv4address and the location identifier. This identifier is sufficientlylong to allow up to 999,999,999 million servers to participate in thenetwork. The location identifier is depicted in FIG. 23.

Server Data Replication

The databases stored on the proxy authentication networks are updatedand replicated using an encrypted shard based data model. This minimizestraffic and allows security of the data. This technique is used byGoogle and others. Only changed data is replicated. The unique aspect ofthis implementation is the shard coordination algorithm stored in thedatabase under control of the network operations center. New data isbroken into shards that are an element of the data and is encrypted anda reassembly index is generated. The data is then routed with a dynamicupdate table under control of the network operations center. The networkoperations module on the server also monitors the activity at the serverand updates are given a priority based on the table being updated. Inthis way a load balancing is accomplished and data that requiresimmediate updating is given the highest priority.

Router Architecture

The node access server functions as a “reverse firewall” to the proxyauthentication network for client requests. Unlike most firewalls, theIP stack is modified to only allow traffic from client data packets. Ina normal firewall, as a connection is made to a resource outside thefirewall a table as in IPF or OpenBSD's pf the software maintains aconnection table. In a node access server, the table is reversed andcontains authenticated device identifiers. In FIG. 18, the Hybrid IPSecprocess examines the packet to see if it has a valid construction. InIPv4 to IPv6 tunneling it also performs fragmentation and reassembly.Upon determining the packet is valid it hands the packet to themessaging interface. The messaging interface examines and optionallydecrypts the payload and determines what to do with it. In FIGS. 19 and20, the two variants are depicted. Those skilled in the art will seethat the scheme involves examining the packet and if it is not destinedto the location, that is the server performing the processing, thepacket is sent on to the appropriate location. In the case of a nodeaccess server, the packet is reconstructed, effectively preventingcommunication from a client to any other server except a node accessserver. This is a function of the Proxy Authentication Network.

Key Generation Server

FIG. 21 depicts the difference in functionality from the other servers.The node access server performs client and device routing andauthentication. The key generation server is where the pairing of entitycredentials to device takes place. It also confirms requests for anentity authentication and generates mutual authentication receipts. FIG.25 depicts the construction of the receipt containing the informationnecessary to allow access to data or a master entity credential.

Storage Access Server

FIG. 22 depicts the difference in functionality from the other servers.The Data Access Policy Filter is the component that manages requests fordata. The database is queried for the appropriate string and if theentity string exists, the appropriate level of access is granted. In thecase of a business or other entity a sub table of strings linked to theentity master table and is queried as well. After determining therequest for data is from a valid entity, the request is passed to theData Request interface where appropriate processing takes place basedupon the type of request received.

ESP Packet Construction

The Encapsulated Security Payload (ESP) is depicted in FIG. 23. A packetvalidation bit is used to verify the packet was constructed by anauthenticated device. Within the Hybrid IPSec stack is an algorithm thatallows this value to be calculated. The location identifier is thedestination of the packet. The module ID is used by the messaginginterface to determine which software module needs to process the restof the packet. The Packet Type is an instruction for the destinationmodule. The ID payload is used when processing device or entityidentifiers. The validation ID is used in various ways to determine thevalidity of the instruction or the identifier. A portion of the packetis reserved for future use in a contemplated messaging applicationprogramming interface for signing messages and a contemplated portalsurfing interface to be used in combination with the age groupidentifier. These are depicted in FIGS. 26A-26B at 4.13 and 4.14. Thematching client functionality is depicted at 5.7 and 5.8. The benefit ofhaving a unique signing of a message is that an audit trail can be used.The benefit of portal surfing allows sites to maintain a content ratingthat can be tied to the age group identifier.

Client Operations

Software Startup

In FIG. 27, the various components of one embodiment are depicted. Thedrivers are started with the operating system to provide a greaterdegree of protection. The other reason for this is because each driverwill latch a register and be prepared for the calling of the driver fromthe service control module. The drivers await instruction from theservice control module after operating system boot. Once the servicecontrol module starts as depicted in FIG. 28, the software authenticatesto the node access server in a process separate from deviceauthentication. In this process, the software receives seed values forthe encryption process that is optionally running on the client device.The diagrams depict a typical personal computer software installation.The seed value is a method for determining that device or networkchanges have not affected the communication process. This is used innormal operation when all device and network identifiers are determinedto be the same as the last device authentication. All movement ofidentifiers are encrypted in RAM on the client device in thisembodiment. FIG. 29 depicts the location of the encryption driverrelative to a personal computer. This allows control of the calls fromthe software. Values are written encrypted into system memory forstorage and data that is to be processed by the CPU can be writtendirectly or subsequently unencrypted from system memory before the CPUperforms an operation. Additionally, the encryption driver can detectintrusions into the process. Address registers are used to pass thedata.

The operation of the startup, device and entity software processes aredepicted in FIG. 31. For the device to begin an entity authenticationthe process depicted in FIG. 32 are performed.

“One Off” Mathematics

One off math is an obfuscation of keys and a client/server process togenerate a new key based on a preliminary calculation from the clientside. This is used to prevent someone from creating a digital copy ofthe data and programs comprising a client machine or authenticationdevice and submitting those values from a different piece of hardware.Without the actual seed value that is derived from the hardware used inthe first authentication process, the algorithm in place on the clientside encrypting program will not create the correct identifier therebyinvalidating the data received by the server.

Those skilled in the art will see that this process may be implementedin a variety of ways. For example, after a secure communication channelis created using the keys generated from an out of band authentication,during the initial device registration process, the client program cangenerate values derived from one or more addressable hardware componentssuch as a processor serial number, hard drive serial number, trustedplatform module or such combination. Each value generated can be storedin a locked register of the processor. As long as no other programattempts to read the values in the locked register, the client programcan then securely transmit these original values from the lockedregister to a server where it is stored. A server process can thengenerate a second value using the original device registration processvalues that are used by the client encryption process which is thenstored on the client. During subsequent authentications of the device,the client uses the server generated values and the values it generatesfrom a hardware detection process that is based on the new values, andtransmits them to a server process that can then use these values todetermine whether the data transmitted is in fact coming from the samehardware device. This same process can be used in validating theauthentication device process. Those skilled in the art will readily seethat this process could be implemented in a variety of methods includingdownloading a replacement client encrypting executable program thatstores the values required to arrive at the required value or other suchimplementations. In this manner, the client generates values derivedfrom hardware that are securely transmitted to the server, and a serverprocess creates new values derived from those values that are sent backto the client. With subsequent authentications of the device, the clientuses a different process using the values sent from the server togenerate values which are sent back to the server and run against aserver process that functions similar to a checksum.

Entity Authentication

When an authentication is called by an application, under control of theentity, through the Identity Announcement Protocol, the process depictedin FIG. 33 begins. Another example of this process is depicted in FIG.30. Those skilled in the art will see that the credentials areconfigured by the user, unlike other systems that require a specificcredential to operate. This drawing also depicts the client encryptionprocess in relation to the gathering of the credentials required by theidentity credential profile.

Web Server or Application Configuration

As business entities requesting authentication will most likely host ona web or other application server, certain adjustments to the identitypairing need to take place. As all software objects, devices andentities are at all times authenticated when requesting data fromanother entity, a subclass table for a software entity is maintained inthe tables. As above the device hosting the application isauthenticated. However, on a web server hosting multiple sites, eachsite must be authenticated separately. This is performed by modifyingthe service control module and installing a DLL or other software foreach site that authenticates each request individually. The softwaremodule would be a DLL in Microsoft HS or an event sink in Apache. Thoseskilled in the art have created many methods for identifying software toan application. The only difference in embodiments of the invention foran application server is that more than one entity may use more than onedevice for authentication but only one set of credentials exists for theserver.

When starting the server, and before the service control module acceptsinput from the various applications, a person must provide credentialsto authorize each software application. While this may done in onecredential input process, out of band authentication will be required tofacilitate the pairing of software module to entity. When delivering asoftware module for an application, the DLL or called code from an eventsink will have compiled into the server a unique encrypted identifier.This is process authentication and is another embodiment of theinvention.

Errata

Most in use protocol designs, TLS, ISAKMP or other, typically employmethods for peer-to-peer communication protocol. There is a preliminaryexchange in order to exchange secrets for communication. In additionnearly all cases the initial exchange is a form of asymmetriccryptography (Diffie-Hellman, El-Gamal etc) which for small devicesintroduces a computational overhead. In the Proxy Authentication Networkall communications already contain the required information and nohandshake or key exchange negotiation is required as the packet isintroduced through a different medium than across the network. In oneembodiment the client software will receive a seed value from a callcenter that is typed in by the user. The software contains what isexpected at the server or further communications is blocked for adeterminate amount of time. Upon a denial the party is sent a messagewith a reactivation number and a credential based call to a call centerthat interacts with the system to deliver the secret to the client andserver. Further communication to the IP address is appended to the “droptable”. In the case of this failure a notice acts to create a newidentifier that is transmitted to the node access server.

In a security enabled environment, in order to protect the information,there can not be a reliance on peer negotiation as the devices uponwhich they are communicating are not authenticated. By introducing athird or even fourth party, in the system monitoring and assistedauthentication function, the party of the first part interacts with theparty of the second part by sharing information with a bi-directionalunilateral authentication proxy between the parties of the third partand the party of the fourth part and so on as the desired level ofauthentication communication security is desired. The invention couldalso be simply a party of the third part acting solely as proxy toauthenticate the user and device on behalf of the party of the firstpart and the party of the second part. In this way the parties' abilityto access pre-encrypted data available to the system requires allparties to participate.

In any case where a network communication between two hosts require asession to take place, the packet expected by the server ispre-authenticated in a separate process for immediate key exchangesetup. This is a shared secret distribution method. The separate processcould include any process that allows the delivery of the packet outsideof the network communication process. For example, the packet could bedistributed on a compact disc medium along with client software toinstall on the target device. The communication server database isupdated with an expected packet. In another frame of reference Alice andBob need to authenticate securely. Alice and Bob are each given amatching session key from a trusted third party Carmen and pass messagesthrough trusted third party Diaz who is already trusted by Carmen. Theactual data is stored at Evelyn. Carmen and Diaz both authenticaterequests to Evelyn for data on behalf of Alice and Bob.

The syntax of the IP Authentication Header is shown in Table 1.

TABLE 1

The diagram above denotes an AH header. In the contemplated Hybridprotocol embodiment the Security Association and the SPI is alreadydetermined and other SPI parameters are removed from the protocol stacktable of associated security parameters. The system utilizes the SPIinternally for verifying the external appended SPI bit by also addingthe SPI bit to the ESP packet. The AH carries the ESP packet(Encapsulated Security Payload) that contains credential data.

The online resource “Webopedia” defines proxy server as “A server thatsits between a client application, such as a Web browser, and a realserver. It intercepts all requests to the real server to see if it canfulfill the requests itself. If not, it forwards the request to the realserver.” Proxy servers are useful for caching content to accelerate therequests and for filtering requests. Some proxy servers supportauthentication, that is before the request is accepted, the clientapplication must prove it is authorized to request the information.

The proxy authentication network is a server or plurality of serversthat functions to proxy authentication requests for confirming thecredentials of an entity or plurality of entities where under control ofa client or server where the device accessing the medium or softwaremaking the request is authenticated to the proxy authentication network,the verification of the credentials under control of the proxyauthentication network, authenticates or mutually authenticates one ormore entities prevents more than one instance of the entity credentialsto be used by more than one device accessing the proxy authenticationnetwork at one time stores encrypted entity data whose decryption keysare under control of one or more trusted servers or plurality of serverscontrols the access to said entity data on behalf of the authenticatingentity or entities.

EXAMPLE IMPLEMENTATION

FIG. 35 shows various computers that are part of the ProxyAuthentication Network of FIG. 1. In FIG. 35, server 3505 is responsiblefor performing authentication. As such, server 3505 can store thevarious tables shown in FIGS. 5-9, among other data. Storages 3510,3515, and 3520 store data for entities. This data, such as data 3525,3530, and 3535, can be personally identifying data that entities do notwant released except under specific circumstances. Server 3505 andstorages 3510, 3515, and 3520 are shown as connected by a single network3540. But a person skilled in the art will recognize that differentnetworks can be used to connect server 3505 and storages 3510, 3515, and3520. Further, although storages 3510, 3515, and 3520 are shown asconnecting directly to server 3505, a person skilled in the art willrecognize that the connections can be configured in any manner desired(for example, server 3505 can be directly connected to storage 3510,which can act as a gateway to storages 3515 and 3520).

Once a subscriber is registered with server 3505 and has data stored inone (or more) of storages 3510, 3525, and 3515, the subscriber can thenperform any desired transaction. While such transactions often includethe transfer of money for some reason, a person skilled in the art willrecognize that any exchange can be negotiated using the ProxyAuthentication Network, not just a transfer of money. For example, asdiscussed above with reference to FIGS. 14-15, the exchange can involvecommunications (that is, the exchange of information/data).

FIG. 36 shows the server of FIG. 35 storing credentials used toauthenticate an entity. In FIG. 36, server 3505 is shown as storingcredentials 3605 and 3610. These credentials can be used to authenticateentities. To support this authentication process, server 3505 includesauthenticator 3615. When an entity needs to be authenticated, theappropriate credential is located and used by authenticator 3615 toauthenticate the entity. Server 3505 also includes receipt generator3620, which is used to generate a receipt that identifies thesubscribers to the system. The receipt generated by receipt generator3620 is designed to identify the subscribers without providing anypersonal identifiable information about either of the subscribers.Although FIG. 36 shows only two credentials for two subscribers, aperson skilled in the art will recognize that server 3505 can storecredentials for any number of subscribers, and that receipt generator3620 can generate a receipt for any number of subscribers in atransaction.

Server 3505 is also shown as including device/location lists 3625 and3630. Device/location lists 3625 and 3630 identify combinations ofdevices and locations that are recognized for individual subscribers.For example, device/location list 3625 can identify recognizedcombinations of devices/locations for one subscriber, anddevice/location list 3630 can identify recognized combinations ofdevice/locations for another subscriber. To provide some examples ofrecognized device/location combinations, one such combination might be acell phone used at a particular ATM location. Another combination mightbe a personal computer using a particular IP address. A person skilledin the art will recognize other device/location combinations that can beused in the Proxy Authentication Network.

FIG. 37 shows the states of the credentials of FIG. 36 being changed.Credentials 3605 and 3610 are shown as including states 3705 and 3710,respectively. Valid states for credentials 3605 and 3610 can include “inuse” and “not in use”. When a credential is in a “in use” state, thesubscriber is currently using the Proxy Authentication Network for somepurpose. By changing the state of the credential, the credential cannotbe used at two places at the same time, which helps to protect againstunauthorized duplicate use of the credential. Thus, when a subscriberbegins an authentication using a credential, the Proxy AuthenticationNetwork sets the state of the credential to “in use”. When a credentialis in a “not in use” state, the credential is available forauthentication of a subscriber, although no current authentication isbeing performed. The Proxy Authentication Network can change the stateof a credential to “not in use” upon a direct instruction from asubscriber, or the Proxy Authentication Network can wait until thetransaction is completed (or some interval thereafter).

To support changing a credential's state, server 3505 includes statesetter 3715. State setter 3715 is responsible for changing states 3705and 3710 as needed. As discussed above, the state can be changed duringthe use of the system. But the state of the credential can also at thedirection of a subscriber. For example, a subscriber could instruct thesystem to disable use of the credential. In that case, the credentialwould not be available for authentication of the entity until the systemis instructed to use the credential again.

FIG. 38 shows an encryption key being assembled from various portions inthe Proxy Authentication Network of FIG. 1. In FIG. 38, various portionsof the key are retrieved from different locations. For example, part 13805 of the key is shown as being stored by server 3505, part 2 3810 ofthe key is shown as being stored by storage 3510, and part 3 3815 of thekey is shown as being stored by third party 3815. Because the key isdivided among several parties, no one party can decrypt the dataindividually. Storage 3510 receives the various portions of the key, andassembles them into the complete key. Data 3525 can then be decrypted.

FIG. 39 shows components of the storage of FIG. 35 used in accessingdata in the storage. Storage 3510 includes transmitter/receiver 3905,key assembler 3910, decrypter 3915, key generator 3920, and encrypter3925. Transmitter/receiver 3905 is responsible receiving andtransmitting information to and from storage 3510. For example,transmitter/receiver 3905 receives the parts of the key stored by otherparties, and transmits the data (once accessed and suitably encrypted)to an appropriate party. Key assembler 3910 is responsible forassembling a key from the various portions. The assembled key can thenbe used by decrypted 3915 to decrypt the data.

Key generator 3920 is responsible for generating a new key that can beused to re-encrypt the data. The reason that the data is decrypted andthen re-encrypted is that the original key remains secure: the new keycan be used to encrypt the data for transmission to a party who issupposed to receive the data. To support this, encrypter 3925 can usethe new key to re-encrypt the data.

In one embodiment, the new key generated by key generator 3920 isprovided to the party in some secure manner. In another embodiment, thenew key is generated based on data known to the both storage 3510 andthe receiving party, so that the party can generate the key and decryptthe received data. In this embodiment, the key is generated can bepartly generated based on additional data, which can be provided to theparty receiving the encrypted data, and partly on data known to bothstorage 3510 and the receiving party. For example, the key can begenerated based in part on the receipt (generated by receipt generator3620 of FIG. 36) and some additional data (e.g., a random value). Bygenerating a new key, the data can be protected against being viewed byan unauthorized party.

FIGS. 40A-40C show a flowchart of the procedure to authenticate anentity in the Proxy Authentication Network of FIG. 1. In FIG. 40A, atstep 4005, the Proxy Authentication Network registers subscribers.Details about how subscribers are registered is shown in FIG. 41. Atstep 4010, a communications channel is established between thesubscribers. At step 4015, the Proxy Authentication Network receivescredentials from the subscribers, and at step 4020, the ProxyAuthentication Network identifies the devices and locations thesubscribers are currently using.

At step 4025 (FIG. 40B), the Proxy Authentication Network checks to seeif the device/location combinations are recognized (that is, in the listof registered devices/locations for the subscribers). If thedevice/location combination for either (or both) subscriber is notrecognized, then at step 4030 the system performs an out-of-bandauthentication. Out-of-band authentication involves using someindependent channel to authenticate the subscriber. Out-of-bandauthentication can be done automatically in some way (for example, usinga device/location combination that is recognized), or can be donemanually (involving an operator of some sort to perform theauthentication). Once the subscriber is authenticated out-of-band, atstep 4035 the system can update the list of recognized device/locationcombinations to recognize the device/location combination from which thesubscriber submitted the credential. Step 4035 can be omitted, as shownby dashed line 4040.

Once the device/location combination from which the subscriber issubmitting the credential is known to be acceptable, at step 4045 theProxy Authentication Network checks that the subscribers' credentialsare currently “not in use”. As discussed above, if a credential is inthe “in use” state, then there is the potential that someone isattempting to fraudulently use the credential. In that case, then atstep 4050 the Proxy Authentication Network indicates that thesubscribers are not authenticated.

If the credentials are not currently “in use”, then at step 4055 (FIG.40C) the Proxy Authentication Network authenticates the subscribersusing their credentials. Once the subscribers are authenticated, then atstep 4060 the Proxy Authentication Network can generate a receipt. Asdiscussed above, this receipt is generated without including anypersonally identifiable information. At step 4065, the receipt istransmitted to the subscribers. The receipt can also be transmitted toother third parties who are being included in the communication. At step4070 the Proxy Authentication Network sets the credentials of thesubscribers to “in use”.

At step 4075, the Proxy Authentication Network checks to see if one ofthe subscribers wants to release their data. If so, then at step 4080the server transmits the portion of the encrypting key stored by theserver to where the data is stored. This enables the storage to decryptthe data for transmission. Finally, at step 4085, the credentials of thesubscribers are set back to “not in use”. As discussed above, thecredentials can be set to “not in use” either when the transaction ends,at the subscribers' direction, or after some interval (when the serverassumes the transaction is complete).

FIG. 41 shows a flowchart of the procedure to add data to a storage inthe Proxy Authentication Network of FIG. 1. At step 4105, the ProxyAuthentication Network receives registration data from the subscribers.This registration data can be personally identifiable information. Thesubscriber can also provide the credential and/or the devices/locationsfrom which the subscriber wants to be authenticated. It should beunderstood that the personally identifiable information is stored instorage, whereas the credential and the device/location combinations aretypically stored in the server. So if the subscriber provides all ofthis information, then the data is partitioned based on what it is, andhandled differently.

Regarding the personally identifiable information, at step 4110 thepersonally identifiable information is encrypted using a key. At step4115, the encrypted data is stored. The storage for the encrypted datacan be selected by the Proxy Authentication Network, or it can beselected by the subscriber (in case the subscriber has a bias about thestorage of his/her/its personally identifiable information). At step4120, the key used to encrypt the personally identifiable information isthen divided. A portion of the key is saved at the storage, and aportion is saved at the server. Additional portions of the key can alsobe provided to third parties, as desired by the subscriber.

FIGS. 42A-42B show a flowchart of the procedure to access data in theProxy Authentication Network of FIG. 1. In FIG. 42A, at step 4205, thestorage receives a receipt of the subscriber's identity from the server.At step 4210, the storage receives a portion of the key used to encryptthe personally identifiable information from the server. At step 4215,the storage accesses the portion of the key stored by the storage. Atstep 4220, the storage can receive additional portions of the key fromthird parties. As shown by dashed arrow 4225, step 4220 can be omittedif the key is not shared among third parties.

At step 4230 (FIG. 42B), the storage assembles the key. At step 4235,the storage uses the key to decrypt the personally identifiableinformation. At step 4240, the storage generates a new key. In oneembodiment, the new key is generated based on the receipt (received fromthe server in step 4205) and other data. At step 4245, the data isre-encrypted using the newly generated key. Finally, at step 4250, there-encrypted data and the other data are transmitted to the requester ofthe data. Note that as the data is encrypted, it is protected fromprying eyes. But given the additional data used by the storage togenerate the key, the requester of the data is able to independentlygenerate the encrypting key, and so decrypt the received data.

FIG. 43 shows a flowchart of the procedure to communicate using a proxyin the Proxy Authentication Network of FIG. 1. At step 4305, onesubscriber sends an encrypted session key to another subscriber. At step4310, the second subscriber requests that a third party act as a proxyfor the communication. At step 4315, the proxy acknowledges thisrequest. At step 4320, the second subscriber notifies the firstsubscriber about the proxy. This notification can use the encryptedsession key. At step 4325, the first subscriber verifies thecommunication using the proxy. At this point, the communication viaproxy is arranged and can be used, satisfying the second subscriber'sdesire for communication via proxy.

The following discussion is intended to provide a brief, generaldescription of a suitable machine (i.e., projector) in which certainaspects of the invention may be implemented. Typically, the machineincludes a system bus to which is attached processors, memory, e.g.,random access memory (RAM), read-only memory (ROM), or other statepreserving medium, storage devices, a video interface, and input/outputinterface ports. The machine may be controlled, at least in part, byinput from conventional input devices, such as keyboards, mice, etc., aswell as by directives received from another machine, interaction with avirtual reality (VR) environment, biometric feedback, or other inputsignal.

The machine may include embedded controllers, such as programmable ornon-programmable logic devices or arrays, Application SpecificIntegrated Circuits, embedded computers, smart cards, and the like. Themachine may utilize one or more connections to one or more remotemachines, such as through a network interface, modem, or othercommunicative coupling. Machines may be interconnected by way of aphysical and/or logical network, such as an intranet, the Internet,local area networks, wide area networks, etc. One skilled in the artwill appreciated that network communication may utilize various wiredand/or wireless short range or long range carriers and protocols,including radio frequency (RF), satellite, microwave, Institute ofElectrical and Electronics Engineers (IEEE) 802.11, Bluetooth, optical,infrared, cable, laser, etc.

The invention may be described by reference to or in conjunction withassociated data including functions, procedures, data structures,application programs, etc., which when accessed by a machine results inthe machine performing tasks or defining abstract data types orlow-level hardware contexts. Associated data may be stored in, forexample, the volatile and/or non-volatile memory, e.g., RAM, ROM, etc.,or in other storage devices and their associated storage media,including hard-drives, floppy-disks, optical storage, tapes, flashmemory, memory sticks, digital video disks, biological storage, etc.Associated data may be delivered over transmission environments,including the physical and/or logical network, in the form of packets,serial data, parallel data, propagated signals, etc., and may be used ina compressed or encrypted format. Associated data may be used in adistributed environment, and stored locally and/or remotely for machineaccess.

Having described and illustrated the principles of the invention withreference to illustrated embodiments, it will be recognized that theillustrated embodiments may be modified in arrangement and detailwithout departing from such principles. And although the foregoingdiscussion has focused on particular embodiments, other configurationsare contemplated. In particular, even though expressions such as“according to an embodiment of the invention” or the like are usedherein, these phrases are meant to generally reference embodimentpossibilities, and are not intended to limit the invention to particularembodiment configurations. As used herein, these terms may reference thesame or different embodiments that are combinable into otherembodiments.

Consequently, in view of the wide variety of permutations to theembodiments described herein, this detailed description and accompanyingmaterial is intended to be illustrative only, and should not be taken aslimiting the scope of the invention. What is claimed as the invention,therefore, is all such modifications as may come within the scope andspirit of the following claims and equivalents thereto.

GLOSSARY

-   Entity An entity is defined as a business, corporation, partnership,    or other fictitious or real persons who have registered with the    system. The term user can be used interchangeably with the term    entity. Typically, a user is meant to describe a physical entity    performing an operation. The term business is considered to be a    business, corporation, or partnership entity registered with the    system hosting an application that is requesting authentication from    the proxy authentication network. The credentials of a business, or    an employee performing functions on behalf of the business entity,    must be registered with the system.-   Credential A credential is one or more combination of identifiers    used by the system to identify an entity or operator to the system.-   Master Credential A master credential is defined as a credential    that is stored by the system and may or may not participate in    authenticating an entity to the system.-   Operator An operator is defined as having control of one or more    servers within the system.-   Identity An identity is defined as the credentials presented by an    entity for authentication to the system.-   Location A location is defined as the point of an interaction by an    entity authenticating.-   Master location A master location is defined as the sovereign    storage location of personally identifiable entity data and/or a    master credential.-   Slave Location A slave location is any entity data storage location    possessing personally identifiable information regarding an entity    that is participating in the system that is not the master location.-   Subscriber An entity that has subscribed to the Proxy Authentication    Network. Where the term entity is used, it should be clear from    context whether the entity is a subscriber or not.-   Entity Data Entity data is defined as data or credentials.

1. A method of authenticating via a computer server, comprising: thecomputer server receiving via a first communications channel anauthentication token from a first authentication client; the computerserver determining an authenticity of the authentication token; and inaccordance with an outcome of the authenticity determining, the computerserver transmitting a payload to a second authentication client via asecond communications channel distinct from the first communicationschannel.
 2. The method according to claim 1, wherein the payload effectsa completion of a transaction with a relying party server distinct fromthe computer server, the authentication token receiving comprises afirst segment of the transaction, and the payload transmitting comprisesa second segment of the transaction.
 3. The method according to claim 1,wherein the first authentication client is provided in a communicationdevice, the authentication token is provided in a hardware tokendistinct from the communication device, and the authentication tokenreceiving comprises the first authentication client requesting theauthentication token from the hardware token, and the computer serverreceiving the requested authentication token from the firstauthentication client.
 4. The method according to claim 3, wherein theauthenticity determining comprises the computer server verifying thatthe authentication token was generated by the hardware token.
 5. Themethod according to claim 1, wherein the first authentication client andthe authentication token are provided in a common communication device,and the authentication token receiving comprises the computer serverreceiving the authentication token released from the communicationdevice.
 6. The method according to claim 1, wherein the authenticationtoken is provided in a credential server, and the authentication tokenreceiving comprises the computer server receiving the authenticationtoken from the credential server.
 7. The method according to claim 1,wherein the payload transmitting comprises the first authenticationclient specifying the second authentication client and the computerserver directing the payload to the specified second authenticationclient.
 8. The method according to claim 1, wherein the payloadtransmitting comprises the computer server identifying the secondauthentication client after receipt of the authentication token, and thecomputer server directing the payload to the identified secondauthentication client.
 9. The method according to claim 1, wherein thepayload transmitting comprises the computer server transmitting asession token to the first authentication client, receiving a payloadrequest from the second authentication client, and transmitting thepayload to the second authentication client in accordance with acorrelation between the payload request and the session token.
 10. Themethod according to claim 9, wherein the payload transmitting furthercomprises the computer server establishing a secure communicationschannel with the second authentication client in accordance with thecorrelation, and transmitting the payload to the second authenticationclient over the secure communications channel, the second communicationschannel comprising the secure communications channel.
 11. The methodaccording to claim 1, wherein the payload comprises an authenticationpayload for facilitating authentication of the second authenticationclient.
 12. The method according to claim 11, wherein the authenticationpayload comprises a session certificate.
 13. The method according toclaim 1, wherein the payload comprises a command for execution by thesecond authentication client.
 14. The method according to claim 13,wherein the command comprises a form-fill command.
 15. Acomputer-readable medium comprising computer processing instructionsstored thereon for execution by a computer, the computer processinginstructions, when executed by the computer, causing the computer toperform the method of claim
 1. 16. A computer server comprising: anauthentication client configured to determine an authenticity of anauthentication token received at the computer server via a firstcommunications channel, and to transmit a payload to a secondauthentication client via a second communications channel distinct fromthe first communications channel in accordance with an outcome of theauthenticity determination.
 17. The computer server according to claim16, wherein the first authentication client is provided in acommunication device, the authentication token is provided in a hardwaretoken distinct from the communication device, and the authenticationclient receives the authentication token from the first authenticationclient.
 18. The computer server according to claim 16, wherein the firstauthentication client and the authentication token are provided in acommon communication device, and the authentication client receives theauthentication token from the communication device.
 19. The computerserver according to claim 16, wherein the authentication token isprovided in a credential server, and the authentication client receivesthe authentication token from the credential server.
 20. The computerserver according to claim 16, wherein the first authentication clientspecifies the second authentication client, and the authenticationclient is configured to direct the payload to the specified secondauthentication client.
 21. The computer server according to claim 16,wherein the authentication client is configured to identify the secondauthentication client after receipt of the authentication token, and todirect the payload to the identified second authentication client. 22.The computer server according to claim 16, wherein the authenticationclient is configured to transmit a session token to the firstauthentication client, receive a payload request from the secondauthentication client, and transmit the payload to the secondauthentication client in accordance with a correlation between thepayload request and the session token.
 23. The computer server accordingto claim 22, wherein the authentication client is configured toestablish a secure communications channel with the second authenticationclient in accordance with the correlation, and transmit the payload tothe second authentication client over the secure communications channel,the second communications channel comprising the secure communicationschannel.
 24. A method of authenticating to a computer server comprising:a first authentication client transmitting an authentication token tothe computer server via a first communications channel; and a secondauthentication client receiving a payload from the computer server via asecond communications channel distinct from the first communicationschannel in accordance with an outcome of a determination of authenticityof the authentication token by the computer server.
 25. The methodaccording to claim 24, wherein the authentication clients areimplemented in a common communication device.
 26. The method accordingto claim 24, wherein the authentication clients are implemented inseparate communication devices.
 27. The method according to claim 24,wherein the first authentication client is provided in a communicationdevice, the authentication token is provided in a hardware tokendistinct from the communication device, and the authentication tokentransmitting comprises the first authentication client requesting theauthentication token from the hardware token and transmitting therequested authentication token to the computer server.
 28. The methodaccording to claim 24, wherein the first authentication client and theauthentication token are provided in a common communication device, andthe authentication token transmitting comprises the communication devicereleasing the authentication token to computer server.
 29. The methodaccording to claim 24, wherein the authentication token is provided in acredential server, and the authentication token transmitting comprisesthe first authentication client authorizing the credential server totransmit the authentication token to the computer server.
 30. The methodaccording to claim 24, wherein the payload receiving comprises the firstauthentication client identifying the second authentication client tothe computer server and the computer server directing the payload to theidentified second authentication client.
 31. The method according toclaim 24, wherein the second authentication client uses the payload toeffect a completion of a transaction with a relying party serverdistinct from the computer server, the authentication token transmittingcomprises a first segment of the transaction, and the payload receivingcomprises a second segment of the transaction.
 32. The method accordingto claim 24, wherein the payload receiving comprises the firstauthentication client receiving a session token from the computerserver, and the second authentication client transmitting a payloadrequest to the computer server and receiving the payload from thecomputer server in accordance with a correlation between the payloadrequest and the session token.
 33. The method according to claim 32,wherein the payload receiving further comprises the secondauthentication client establishing a secure communications channel withthe computer server in accordance with the correlation, and receivingthe payload over the secure communications channel, the secondcommunications channel comprising the secure communications channel. 34.The method according to claim 24, wherein the payload comprises anauthentication payload, and the second authentication clientauthenticates itself using the authentication payload.
 35. The methodaccording to claim 34, wherein the authentication payload comprises asession certificate.
 36. The method according to claim 24, wherein thepayload comprises a command, and the second authentication clientexecutes the received command.
 37. The method according to claim 36,wherein the command comprises a form-fill command.
 38. A communicationdevice comprising: a first authentication client configured to transmitan authentication token to a computer server via a first communicationschannel; and a second authentication client configured to receive apayload from the computer server via a second communications channeldistinct from the first communications channel in accordance with anoutcome of a determination of authenticity of the authentication tokenby the computer server.